1 Pendahuluan

Untuk suatu Algoritme f, dua peserta yang saling tidak percaya, Alice dan Bob, dapat membangun kepercayaan dengan cara berikut:

1. Alice memasukkan x, menjalankan fungsi Algoritme f, dan mendapatkan hasil y. Bob juga menggunakan input x yang sama untuk menjalankan fungsi Algoritme f, dan mendapatkan y′. Jika y dan y′ sama, Bob akan mengakui input x dan output y yang diberikan oleh Alice. Ini adalah mekanisme bukti validitas yang umum, yang biasanya digunakan dalam konsensus Blok, di mana Alice adalah Node yang mengemas Blok, sementara Bob adalah Node yang berpartisipasi dalam Konsensus.
2. Alice memasukkan x, menjalankan program zk.prove, dan mendapatkan hasil y dan bukti proof. Bob menjalankan program zk.verify berdasarkan f, y, dan proof. Jika hasilnya benar, Bob akan mengakui hasil y dari Alice; jika hasilnya salah, Bob tidak akan mengakui hasil y dari Alice. Ini adalah jenis bukti validitas, Bob bisa menjadi kontrak on-chain.
3. Alice memasukkan x, menjalankan Algoritme f, dan mendapatkan hasil y. Bob juga menggunakan input yang sama x untuk menjalankan Algoritme f dan mendapatkan y'. Jika y dan y' sama, tidak ada yang dilakukan; jika y dan y' tidak sama, Bob akan menantang Alice dengan program f. Interaksi antara Alice dan Bob dapat dilakukan dalam satu atau beberapa putaran. Penyelesaian dilakukan melalui mekanisme tantangan-respons. Ini adalah bukti penipuan, di mana Bob adalah penantang yang mendengarkan secara offline dan menantang secara online.
4. Alice memasukkan x, menjalankan program zk.prove, dan mendapatkan hasil y dan bukti proof. Bob menjalankan program zk.verify berdasarkan f, y, dan proof. Jika hasilnya benar, tidak ada tindakan yang diambil; jika hasilnya salah, Bob akan menantang Alice dengan program zk.verify. Interaksi antara Alice dan Bob dapat terjadi dalam satu putaran atau beberapa putaran. Penyelesaian dilakukan melalui mekanisme tantangan-tanggapan. Ini merupakan jenis bukti penipuan, di mana Bob sebagai penantang, mendengarkan secara offline dan menantang secara online.

Untuk 2, 3, dan 4 di atas, dengan x sebagai transaksi Layer2 dan status awal, f sebagai program Konsensus Layer2, dan y sebagai status akhir transaksi, ini sesuai dengan solusi ekstensi Layer2 blockchain.

• bukti validitas: Berdasarkan asumsi pesimis, harus dibuktikan keabsahan sebelum diterima dan berlaku segera. Dalam bukti validitas, bukti transisi status L2 yang benar harus disediakan, mencerminkan pandangan pesimis terhadap dunia - hanya akan diterima jika status terbukti benar.
• bukti penipuan：Berdasarkan asumsi optimis, secara default itu diterima kecuali ada yang membuktikan sebaliknya. Ini memiliki jendela tantangan di mana hanya setelah jendela tantangan berakhir itu akan efektif. Dalam bukti penipuan, harus disediakan bukti transisi status L2 yang tidak benar, mencerminkan pandangan optimis terhadap dunia - transisi status dianggap benar kecuali ada bukti sebaliknya.

Tabel 1: Metode Membangun Kepercayaan

Selain itu, perlu diperhatikan bahwa:

• Kunci untuk membedakan bukti penipuan dan bukti validitas bukanlah apakah menggunakan sistem bukti ZK seperti SNARK atau STARK. Sistem bukti ZK hanya mengekspresikan metode bukti yang digunakan, sedangkan penipuan atau validitas mewakili konten bukti. Oleh karena itu, skenario 1 dalam Tabel 1 disebut sebagai bukti validitas.
• bukti validitas memiliki keunggulan dalam validitas yang lebih baik, namun kompleksitas verifikasi on-chain lebih tinggi; sementara verifikasi on-chain bukti penipuan memiliki kompleksitas yang lebih rendah, namun validitas yang lebih buruk.
• Untuk kasus 2 dan 4 dalam tabel 1, dengan menggunakan teknologi rekursif ZK dan komposisi, banyak f dapat dihitung dan dikompresi, sehingga secara signifikan menurunkan biaya verifikasi komputasi pada on-chain terhadap off-chain.

Saati ini, berkat Smart Contract Turing Complete Solidity, teknologi bukti penipuan dan bukti validitas telah banyak digunakan dalam perluasan Layer2 Ethereum. Namun, di bawah kerangka BTC, karena keterbatasan fungsi opcode BTC, jumlah elemen tumpukan hanya 1000, dan pembatasan lainnya, aplikasi teknologi ini masih dalam tahap eksplorasi. Artikel ini merangkum keterbatasan dan teknologi terobosan di bawah kerangka BTC, meneliti teknologi bukti validitas dan bukti penipuan, serta menggambarkan teknologi script segmentasi unik di bawah kerangka BTC.

Batasan dan Terobosan dalam Paradigma 2 BTC

Dalam kerangka BTC, ada banyak keterbatasan, tetapi keterbatasan ini dapat diatasi dengan berbagai cara atau teknologi yang cerdik. Misalnya, menggunakan Bit komitmen dapat mengatasi batasan keadaan tanpa UTXO, Taproot dapat mengatasi batasan ruang skrip, output penghubung dapat mengatasi batasan cara konsumsi UTXO, sementara Smart Contract dapat mengatasi batasan pra-tanda tangan.

2.1 Model UTXO dan Batasan Skrip

BTC menggunakan model UTXO, di mana setiap UTXO dikunci dalam sebuah skrip kunci yang mendefinisikan kondisi yang harus dipenuhi untuk menghabiskan UTXO tersebut. Ada beberapa batasan pada skrip BTC:

1. Skrip BTC adalah tidak berkeadaan;
2. Untuk jenis output P2TR, maksimal 4 juta opcode dapat ditampung dalam satu transaksi, mengisi seluruh Blok, sedangkan untuk jenis output lainnya, hanya dapat menggunakan 10.000 opcode.
3. Cara pengeluaran UTXO tunggal terbatas, kurangnya eksplorasi terhadap cara pengeluaran kombinasi;
4. Tidak mendukung fitur kontrak fleksibel;
5. Batas ukuran tumpukan adalah maksimum 1000 elemen (termasuk altstack dan stack), dengan ukuran maksimum satu elemen adalah 520 byte;
6. Operasi aritmatika (seperti penambahan dan pengurangan) dibatasi hingga 4 elemen byte, tidak dapat diperluas menjadi elemen panjang 20 byte atau lebih besar, ini diperlukan dalam operasi enkripsi;
7. Kode operasi seperti OPMUL dan OPCAT telah dinonaktifkan, menggunakan kode operasi yang ada untuk mensimulasikan mereka sangat mahal, misalnya mensimulasikan hash BLAKE3 satu kali, ukuran skripnya sekitar 75K.

2.2 Komitmen Bit: Melewati Batasan Status UTXO

Saat ini, skrip BTC benar-benar tanpa status. Saat menjalankan skrip BTC, lingkungan eksekusi setiap skrip akan diatur ulang setelah selesai. Hal ini membuat skrip BTC tidak dapat mendukung skrip pembatasan 1 dan 2 yang berbagi nilai x secara alami. Namun, masalah ini dapat diatasi dengan beberapa metode, dengan ide inti adalah menandatangani suatu nilai dengan cara tertentu. Jika dapat menghasilkan tanda tangan untuk sebuah nilai, maka skrip BTC dapat memiliki status. Dengan kata lain, dengan memeriksa tanda tangan nilai x dalam skrip 1 dan 2, dapat dipastikan bahwa nilai x yang sama digunakan dalam kedua skrip tersebut. Jika terdapat tanda tangan yang bertentangan, yakni menandatangani dua nilai yang berbeda untuk variabel x yang sama, maka hukuman dapat diberlakukan. Metode ini disebut Bit komitmen.

Prinsip yang dijanjikan oleh Bit relatif sederhana. Setiap Bit sesuai dengan dua nilai hash yang berbeda, hash0 dan hash1. Jika nilai Bit yang akan ditandatangani adalah 0, maka ditunjukkan awal hash0; jika nilai Bit adalah 1, maka ditunjukkan awal hash1.

Sebagai contoh, untuk pesan Bit tunggal m ∈ {0,1}, skrip pengungkapan Bit yang sesuai hanya terdiri dari beberapa pra-gambar: jika nilai Bit adalah 0, maka skrip pengungkapan adalah preimage0 - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; jika nilai Bit adalah 1, maka skrip pengungkapan adalah preimage1 - "0x47c31e611a3bd2f3a7a42207613046703fa27496". Oleh karena itu, melalui komitmen Bit, pembatasan tanpa status UTXO dapat dilanggar, mewujudkan skrip BTC berstatus, dan akhirnya memungkinkan berbagai fitur baru yang menarik.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Ini adalah hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Ini adalah hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Nilai yang dijanjikan oleh Bit sekarang ada di atas tumpukan. Itu bisa berupa "0" atau "1".

Saat ini, Bit memiliki dua cara implementasi yang dijanjikan:

• Tanda tangan satu kali Lamport: Prinsip tanda tangan satu kali Lamport relatif sederhana, hanya memerlukan fungsi hash, cocok dengan BTC. Untuk setiap Bit dalam pesan, dua nilai hash perlu dijanjikan, yang menyebabkan data tanda tangan relatif besar. Secara khusus, untuk pesan dengan panjang v Bit, panjang Kunci Publik adalah 2v Bit, sedangkan panjang tanda tangan adalah v Bit.
• Tanda tangan satu kali Winternitz: Dibandingkan dengan tanda tangan Lamport, tanda tangan Winternitz secara signifikan mengurangi panjang dari tanda tangan dan Kunci Publik, tetapi meningkatkan kompleksitas dari tanda tangan dan verifikasi. Skema ini memungkinkan pengaturan fleksibel dari panjang rantai hash d yang berbeda sesuai kebutuhan, sehingga mencapai keseimbangan antara panjang dan kompleksitas. Misalnya, mengatur d = 15 dapat membuat panjang Kunci Publik dan tanda tangan menjadi sekitar 4 kali lebih pendek, tetapi kompleksitas verifikasi akan meningkat 4 kali lipat. Ini sebenarnya adalah keseimbangan antara ukuran tumpukan BTC dan ukuran skrip. Ketika d = 1, tanda tangan Lamport dapat dianggap sebagai kasus khusus dari tanda tangan Winternitz.

Saat ini, perpustakaan BitVM2 mengimplementasikan tanda tangan Winternitz berdasarkan fungsi hash Blake3. Panjang tanda tangan untuk satu Bit adalah sekitar 26 byte. Oleh karena itu, dapat dilihat bahwa memperkenalkan status melalui Bit komitmen memiliki biaya. Oleh karena itu, dalam implementasi BitVM2, pesan pertama-tama di-hash untuk mendapatkan nilai hash 256 bit, kemudian komitmen Bit dilakukan terhadap nilai hash tersebut untuk menghemat biaya, bukan langsung melakukan komitmen terhadap setiap Bit pesan asli yang lebih panjang.

2.3 Taproot：TAPROOT: Melewati Batasan Ruang Skrip

Penyempurnaan lunak Taproot BTC diaktifkan pada November 2021, termasuk tiga proposal: tanda tangan Schnorr (BIP 340), Taproot (BIP 341), dan TapScript (BIP 342). Upgrade ini memperkenalkan jenis transaksi baru - transaksi Pay-to-Taproot (P2TR). Dengan menggabungkan keunggulan Taproot, MAST (Merkel Abstract Syntax Tree), dan tanda tangan Schnorr, transaksi P2TR dapat membuat format transaksi yang lebih pribadi, fleksibel, dan dapat diperluas.

P2TR mendukung dua cara pengeluaran: melalui jalur Kunci Rahasia atau jalur skrip. Sesuai dengan aturan Taproot (BIP 341), saat melakukan pengeluaran melalui jalur skrip, panjang jalur Merkle yang sesuai tidak boleh melebihi 128. Ini berarti jumlah daun tapleaf dalam taptree tidak boleh lebih dari 2^128. Sejak peningkatan SegWit pada tahun 2017, jaringan BTC mengukur ukuran Blok dalam satuan bobot, dengan dukungan maksimal 4 juta satuan bobot (sekitar 4MB). Ketika output P2TR dikeluarkan melalui jalur skrip, hanya perlu mengungkapkan satu skrip tapleaf tunggal, yang berarti Blok hanya mengandung satu skrip tapleaf. Oleh karena itu, untuk transaksi P2TR, ukuran skrip yang sesuai dengan setiap tapleaf dapat mencapai sekitar 4MB. Namun, berdasarkan kebijakan default BTC, banyak Node hanya meneruskan transaksi yang kurang dari 400K; transaksi yang lebih besar perlu dikemas dengan kerjasama dengan Penambang.

Taproot membawa premi ruang skrip yang membuat operasi kriptografi seperti perkalian dan hash menjadi lebih berharga dengan menggunakan opcode yang ada untuk mensimulasikannya. Ketika membangun komputasi yang dapat diverifikasi berbasis P2TR, ukuran skrip tidak lagi terbatas pada 4MB, tetapi bisa dibagi menjadi beberapa subfungsi yang tersebar di banyak tapleaf, sehingga melampaui batasan 4MB ruang skrip. Secara faktual, validator Algoritme Groth16 yang diimplementasikan dalam BitVM2 saat ini memiliki ukuran hingga 2GB. Namun, itu dapat dibagi dan didistribusikan di sekitar 1000 tapleaf, dan dengan kombinasi dengan komitmen Bit, membatasi konsistensi antara input dan output setiap subfungsi, sehingga memastikan integritas dan kebenaran dari seluruh komputasi.

2.4 Output Konektor: Melewati Batasan Metode Pengeluaran UTXO

Saat ini, BTC menyediakan dua cara pengeluaran asli untuk setiap output transaksi yang belum dihabiskan (UTXO): melalui skrip atau Kunci Publik. Oleh karena itu, UTXO dapat dihabiskan asalkan memenuhi tanda tangan Kunci Publik yang benar atau kondisi skrip. Dua UTXO dapat dihabiskan secara independen, dan tidak dapat ditambahkan pembatasan untuk membatasi kedua UTXO ini, yang berarti harus memenuhi kondisi tambahan untuk dapat menghabiskannya.

Namun, pendiri Ark protokol, Burak, dengan cerdik menggunakan tanda SIGHASH untuk mengimplementasikan output penghubung. Secara khusus, Alice dapat membuat tanda tangan yang akan mengirimkan BTC-nya ke Bob. Karena tanda tangan dapat berkomitmen pada beberapa input, Alice dapat mengatur tanda tangannya sebagai kondisi: tanda tangan transaksi Taketx hanya akan valid jika input kedua dikonsumsi. Input kedua ini disebut penghubung, yang menghubungkan UTXO A dan UTXO B. Dengan kata lain, transaksi Taketx hanya akan valid jika UTXO B tidak dikonsumsi oleh transaksi Challengetx. Oleh karena itu, dengan menghancurkan output penghubung, validitas transaksi Taketx dapat dicegah.

Gambar 1: Diagram Output Konektor

Dalam protokol BitVM2, output connector berperan sebagai fungsi if...else. Begitu output connector dihabiskan oleh transaksi tertentu, output tersebut tidak dapat dihabiskan lagi oleh transaksi lain, sehingga memastikan eksklusivitasnya. Dalam implementasi nyata, untuk memungkinkan siklus tantangan-respons, ditambahkan UTXO tambahan dengan kunci waktu. Selain itu, output connector juga dapat mengatur kebijakan pengeluaran yang berbeda sesuai kebutuhan, misalnya dalam kasus transaksi tantangan memungkinkan salah satu pihak untuk mengeluarkan dana, sementara dalam kasus transaksi respons hanya operator yang diizinkan untuk mengeluarkan dana, atau memungkinkan siapa pun untuk mengeluarkan dana setelah batas waktu tertentu.

2.5 Kontrak: Melampaui Batasan Pra-Tanda Tangan

Saat ini, skrip BTC terutama membatasi kondisi yang harus dipenuhi untuk membuka kunci, tetapi tidak membatasi bagaimana output transaksi yang belum dihabiskan (UTXO) dapat digunakan lebih lanjut. Hal ini dikarenakan skrip BTC tidak dapat membaca konten transaksi itu sendiri, sehingga tidak dapat melakukan introspeksi terhadap transaksi. Jika skrip BTC dapat memeriksa konten apa pun dari transaksi (termasuk output), maka fungsi kontrak dapat diimplementasikan.

Implementasi kontrak saat ini dapat dibagi menjadi dua jenis:

• Pra-penyepakatan: Berdasarkan kemampuan skrip BTC yang ada, kontrak prapesan dengan fungsi terbatas dibangun melalui pra-penyepakatan. Ini berarti para peserta perlu merancang dan menandatangani semua transaksi masa depan yang mungkin, sehingga mengunci mereka pada Kunci Pribadi dan tingkat biaya tertentu. Beberapa skema bahkan mengharuskan peserta untuk menghasilkan Kunci Pribadi sementara untuk semua transaksi pra-penyepakatan. Setelah pra-penyepakatan selesai, Kunci Pribadi sementara ini akan dihapus dengan aman untuk mencegah penyerang mengakses dan mencuri dana. Namun, proses ini perlu diulang setiap kali ada penambahan peserta baru atau pembaruan, menyebabkan biaya perawatan yang tinggi. Sebagai contoh, Jaringan Lighting mencapai kontrak dua pihak melalui pra-penyepakatan, dan menggunakan teknologi Kontrak Waktu Kunci hash (HTLC) untuk rute beberapa kontrak dua pihak, sehingga menerapkan strategi perluasan minimal kepercayaan. Namun, Jaringan Lighting perlu pra-penyepakan banyak transaksi, terbatas hanya pada dua pihak, sehingga menggunakan sistem ini terasa rumit; di BitVM1, ratusan transaksi perlu dipra-penyepakatan setiap kali inisialisasi, sedangkan di BitVM2 yang dioptimalkan, jumlah transaksi yang perlu dipra-penyepakatan setiap kali inisialisasi juga mencapai puluhan. Di BitVM1 dan BitVM2, hanya operator yang terlibat dalam pra-penyepakan yang memenuhi syarat untuk mendapatkan penggantian. Jika ada n peserta yang terlibat dalam pra-penyepakan, setiap peserta perlu mempra-penyepakatan m transaksi, sehingga kompleksitas pra-penyepakan setiap peserta akan menjadi n * m.
• Memperkenalkan opcode kontrak: Memperkenalkan opcode fungsi kontrak baru dapat secara signifikan mengurangi kompleksitas komunikasi antara peserta kontrak dan biaya pemeliharaan, sehingga memberikan cara yang lebih fleksibel untuk menerapkan kontrak bagi BTC. Misalnya, opcode OPCAT digunakan untuk menghubungkan byte string. Meskipun fungsinya sederhana, namun sangat kuat, dapat secara signifikan mengurangi kompleksitas BitVM; opcode OPTXHASH memungkinkan pengendalian yang lebih detail terhadap operasi dalam kontrak. Jika digunakan dalam BitVM, dapat mendukung rentang operator yang lebih luas, sehingga secara signifikan meningkatkan keamanan BitVM dan meminimalkan kepercayaan. Selain itu, metode pra-tanda tangan pada dasarnya berarti operator dalam BitVM hanya dapat menggunakan proses penggantian, yang mengakibatkan efisiensi penggunaan modal yang lebih rendah; namun melalui opcode kontrak baru, mungkin dapat membayar langsung kepada pengguna output dari kolam dana peg-in, yang lebih meningkatkan efisiensi modal. Oleh karena itu, model kontrak yang fleksibel akan secara efektif menembus batasan pra-tanda tangan tradisional.

3 Bitcoin Layer2 Skala: bukti validitas dan bukti penipuan

bukti validitas dan bukti penipuan dapat digunakan untuk ekstensi Layer2 BTC, perbedaan utama tercantum dalam tabel 2.

Tabel 2: Bukti validitas vs. bukti penipuan

Dengan didasarkan pada Bit, Taproot, tanda tangan pra-tanda tangan, dan output pemateri, dapat membangun bukti penipuan berdasarkan BTC. Selain itu, dengan memperkenalkan opcode kontrak (misalnya OP_CAT), juga dapat membangun bukti validitas BTC berdasarkan Taproot. Selain itu, bukti penipuan dapat dibagi menjadi bukti penipuan berizin dan bukti penipuan tanpa izin berdasarkan apakah Bob masuk ke dalam sistem. Dalam bukti penipuan berizin, hanya kelompok tertentu yang dapat menantang sebagai Bob, sementara dalam bukti penipuan tanpa izin, pihak ketiga mana pun dapat menantang sebagai Bob. Keamanan bukti penipuan tanpa izin lebih unggul daripada bukti penipuan berizin karena mengurangi risiko kolusi antara peserta.

Berdasarkan jumlah interaksi tantangan-respons antara Alice dan Bob, bukti penipuan dapat dibagi menjadi bukti penipuan satu putaran dan bukti penipuan multi-putaran, seperti yang ditunjukkan pada Gambar 2.

Gambar 2: Bukti penipuan tunggal versus bukti penipuan multipel

Seperti yang ditunjukkan dalam Tabel 3, bukti penipuan dapat diimplementasikan melalui berbagai model interaksi, termasuk model interaksi satu putaran dan model interaksi banyak putaran.

Tabel 3: Interaksi Satu Putaran dan Interaksi Berputar Banyak

Dalam paradigma perluasan Layer2 BTC, BitVM1 menggunakan mekanisme bukti penipuan multi-putaran, sedangkan BitVM2 menggunakan mekanisme bukti penipuan satu-putaran, dan bitcoin-circle stark menggunakan bukti validitas. Dalam beberapa mekanisme ini, BitVM1 dan BitVM2 dapat diimplementasikan tanpa mengubah protokol BTC, sementara bitcoin-circle stark membutuhkan pengenalan Kode Operasi OP_CAT baru.

Untuk sebagian besar tugas komputasi, signet BTC, testnet, dan mainnet tidak sepenuhnya mendukung skrip 4MB, oleh karena itu perlu menggunakan teknologi pemisahan skrip, yaitu membagi skrip komputasi lengkap menjadi blok yang lebih kecil dari 4MB dan mendistribusikannya di Tapleaf yang berbeda.

3.1 Bitcoin多轮bukti penipuan

Seperti yang ditunjukkan dalam Tabel 3, bukti penipuan multi-round cocok untuk situasi di mana ingin mengurangi perhitungan arbitrase on-chain, atau tidak dapat secara langsung mengidentifikasi segmen perhitungan masalah. Sesuai namanya, bukti penipuan multi-round memerlukan interaksi multi-round antara pihak yang memberikan bukti dan validator untuk menemukan segmen perhitungan masalah, kemudian melakukan arbitrase berdasarkan segmen-segmen tersebut.

White Paper BitVM Robin Linus sebelumnya (biasanya disebut BitVM1) menggunakan metode penipuan bukti berulang. Diasumsikan setiap periode tantangan berlangsung selama satu minggu, dan menggunakan metode pencarian biner untuk mencari segmen perhitungan masalah, periode respons tantangan on-chain validator Groth16 dapat diperpanjang hingga 30 minggu, menyebabkan kurangnya keterandalan. Meskipun saat ini ada tim yang sedang mengkaji metode pencarian n-ary yang lebih efisien daripada pencarian biner, tetapi keterandalannya masih jauh lebih rendah daripada siklus penipuan bukti tunggal selama 2 minggu.

Saat ini, tantangan izin penggunaan multi-bukti penipuan dalam BTC ditantang, sementara metode tunggal bukti penipuan telah menerapkan metode tanpa izin, sehingga mengurangi risiko kolusi antara peserta dan meningkatkan keamanan. Oleh karena itu, Robin Linus memanfaatkan keuntungan Taproot untuk mengoptimalkan BitVM1, tidak hanya mengurangi jumlah interaksi menjadi satu putaran, tetapi juga memperluas metode tantangan menjadi tanpa izin, meskipun ini meningkatkan biaya perhitungan arbitrase on-chain.

3.2 Bitcoin putaran bukti penipuan

Dalam model ini, verifikasi bukti penipuan hanya memerlukan satu kali interaksi antara validator dan verifier. Validator hanya perlu memulai satu kali tantangan, sedangkan verifier hanya perlu merespons sekali. Dalam responsnya, verifier harus menyediakan bukti untuk membuktikan bahwa perhitungannya benar. Jika validator menemukan ketidaksesuaian dalam bukti tersebut, maka tantangan berhasil; jika tidak, maka tantangan gagal. Fitur bukti penipuan interaksi tunggal seperti yang ditunjukkan dalam tabel 3.

Gambar 3: Bukti penipuan tunggal

Pada tanggal 15 Agustus 2024, Robin Linus merilis White Paper teknis BitVM2: Menghubungkan BTC ke lapisan kedua, di mana ia mengimplementasikan cross-chain bridges yang menggunakan metode bukti penipuan tunggal yang mirip dengan yang ditunjukkan pada gambar 3.

3.3 Menggunakan BTCbukti validitas OP_CAT

OP_CAT adalah bagian dari bahasa skrip BTC yang dilarang karena kerentanan keamanan pada tahun 2010. Namun demikian, komunitas BTC telah lama membahas kemungkinan untuk mengaktifkan kembali OP_CAT. Saat ini, OP_CAT telah diberi nomor 347 dan diaktifkan di jaringan signet BTC.

Fungsi utama OP_CAT adalah menggabungkan dua elemen dalam tumpukan dan mendorong hasilnya kembali ke tumpukan. Fungsi ini memberikan peluang baru bagi kontrak di BTC dan verifikator STARK.

• Kontrak: Andrew Poelstra mengusulkan CAT dan Trik Schnorr I, menggunakan teknologi OP_CAT dan Schnorr untuk mengimplementasikan kontrak di BTC. Schnorr Algoritme adalah jenis Tanda Tangan Digital yang dapat digunakan untuk jenis output P2TR; untuk jenis output lainnya, teknologi ECDSA serupa dapat digunakan, seperti yang ditunjukkan dalam kontrak CAT dan ECDSA. Dengan kontrak OP_CAT, validator Algoritme STARK dapat dipecah menjadi beberapa transaksi, secara bertahap memverifikasi seluruh bukti STARK.
• STARK Verifier: Fungsi utama dari Verifier STARK adalah menghubungkan dan melakukan hash data. Berbeda dengan operasi aljabar, hash adalah operasi asli dalam skrip BTC yang dapat mengurangi biaya secara signifikan. Misalnya, OPSHA256 dalam bentuk asli adalah opcode tunggal, sedangkan versi simulasi membutuhkan ratusan opcode. Operasi hash utama dalam STARK termasuk memverifikasi jalur Merkle dan konversi Fiat-Shamir. Oleh karena itu, OP_CAT sangat ramah terhadap Verifier STARK Algoritme.

3.4 Teknologi Pemisahan Skrip BTC

Meskipun setelah bukti SNARK/STARK, beban komputasi yang diperlukan untuk proof of validarion jauh lebih rendah dibandingkan menjalankan langsung komputasi asli f, namun jumlah skrip yang diperlukan untuk mengubahnya menjadi Algoritme verifikator BTC masih besar. Saat ini, berdasarkan opcode BTC yang ada, ukuran skrip verifikator Groth16 dan Fflonk yang dioptimalkan masing-masing melebihi 2GB, sementara ukuran satu Blok BTC hanya 4MB, sehingga tidak mungkin menjalankan seluruh skrip verifikator dalam satu Blok tunggal. Namun, sejak upgrade Taproot, BTC mendukung eksekusi skrip melalui tapleaf, yang memungkinkan skrip verifikator dibagi menjadi beberapa blok, dengan setiap blok membangun taptree sebagai tapleaf. Konsistensi antar blok dapat dijamin melalui komitmen bit.

Dalam kasus kontrak OP_CAT, validator STARK dapat dibagi menjadi beberapa transaksi standar yang lebih kecil dari 400KB, sehingga verifikasi bukti validitas STARK secara keseluruhan dapat diselesaikan tanpa perlu bekerja sama dengan Penambang  .

Bagian ini akan secara khusus mengenalkan teknik pemecahan skrip BTC dalam keadaan yang ada, tanpa memperkenalkan atau mengaktifkan opcode baru.

Saat membagi skrip, perlu seimbangkan informasi dari beberapa aspek berikut:

• Ukuran skrip blok tunggal tidak boleh melebihi 4MB dan harus mencakup skrip komitmen input, tanda tangan transaksi, dan konten lainnya.
• Ukuran tumpukan maksimum satu blok tidak boleh melebihi 1000. Oleh karena itu, tumpukan setiap blok harus hanya menyimpan elemen yang diperlukan untuk memastikan cukup ruang tumpukan untuk optimasi ukuran skrip, karena Pencucian Uang BTC tidak terkait dengan ukuran tumpukan.
• Di atas BTC, biaya komitmen bit terlalu tinggi. Oleh karena itu, input dan output harus diminimalkan antara dua blok berturut-turut, di mana 1 bit saat ini setara dengan 26 byte.
• Untuk memudahkan audit, fungsi setiap blok harus sejelas mungkin.

Saat ini, metode pemecahan skrip dapat dibagi menjadi tiga kategori berikut:

• Pembagian Otomatis: Metode ini mencari cara pembagian sehingga ukuran skrip sekitar 3MB dan meminimalkan ukuran tumpukan dan ukuran skrip dasar. Keuntungannya adalah independen dari Algoritme verifikator tertentu dan dapat diperluas ke pembagian skrip perhitungan apa pun. Kekurangannya termasuk: (1) seluruh blok logika harus ditandai secara terpisah, misalnya blok kode OP_IF yang tidak dapat dibagi; jika tidak, hasil eksekusi skrip pembagian mungkin salah; (2) hasil eksekusi blok mungkin sesuai dengan beberapa elemen di tumpukan, dan perlu menandai jumlah elemen tumpukan yang diperlukan untuk komitmen bit yang diterapkan sesuai dengan logika perhitungan aktual; (3) fungsi logika setiap skrip blok sulit dibaca, sulit diaudit; (4) tumpukan mungkin berisi elemen yang tidak diperlukan oleh blok berikutnya, membuang ruang tumpukan.
• Pemisahan Fungsi: Metode ini memecah berdasarkan subfungsi fungsional dalam perhitungan, dengan jelas menentukan masukan dan keluaran setiap subfungsi. Pada saat memecah skrip, setiap blok diimplementasikan dengan skrip komitmen bit yang diperlukan, untuk memastikan ukuran total skrip blok akhir tidak melebihi 4MB, dan ukuran tumpukan tidak melebihi 1000. Keuntungannya adalah kejelasan fungsi, logika yang jelas, dan mudah dibaca, sehingga memudahkan dilakukan audit. Kekurangannya adalah logika perhitungan asli mungkin tidak cocok dengan logika tingkat skrip, subfungsi asli mungkin yang terbaik, tetapi tidak selalu menggambarkan keunggulan tingkat skrip.
• Pembelahan Manual: Titik pembelahan metode ini bukanlah berdasarkan subfungsi fungsional, tetapi diatur secara manual. Metode ini sangat cocok untuk kasus di mana ukuran subfungsi tunggal melebihi 4MB. Keuntungannya adalah memungkinkan pembelahan manual subfungsi skrip besar, seperti subfungsi yang terkait dengan perhitungan Fq12; setiap blok logis jelas dan mudah dibaca, memudahkan audit. Kerugiannya adalah terbatas pada kemampuan penyetelan manual, setelah optimisasi skrip keseluruhan, titik pembelahan manual yang telah diatur sebelumnya mungkin tidak lagi optimal, dan perlu disesuaikan kembali.

Misalnya, setelah beberapa ronde optimasi, ukuran skrip validator Groth16 telah turun dari sekitar 7GB menjadi sekitar 1.26GB. Selain optimasi perhitungan secara keseluruhan, setiap blok juga dapat dioptimalkan secara individu untuk memaksimalkan penggunaan ruang tumpukan. Misalnya, dengan menggunakan algoritma tabel pencarian yang lebih efisien, serta memuat dan membuang tabel pencarian secara dinamis, ukuran skrip setiap blok dapat lebih diperkecil.

Karena biaya komputasi dan lingkungan operasional bahasa pemrograman Web2 yang berbeda jauh dengan skrip BTC, maka mentransformasikan implementasi Algoritme yang ada ke skrip BTC dengan cara yang sederhana tidaklah memungkinkan. Oleh karena itu, perlu mempertimbangkan optimasi khusus untuk skenario BTC:

• Mencari Algoritme yang dapat mengoptimalkan localitas memori, meskipun ini mungkin menambah beban komputasi, untuk mengurangi jumlah input/output antar blok, sehingga menurunkan jumlah data yang dibutuhkan dalam desain transaksi assertTx BitVM2.
• Dengan menggunakan sifat pertukaran operasi terkait (misalnya, operasi logika), seperti x&y = y&x, untuk menghemat hampir separuh ruang tabel pencarian.
• Saat ini, skrip yang dioperasikan oleh Fq12 memiliki ukuran yang besar; dapat dipertimbangkan untuk menggunakan skema Fiat-Shamir, Schwartz-Zipple, dan komitmen polinomial untuk secara signifikan menurunkan kompleksitas perhitungan operasi perluasan Fq12.

4 Kesimpulan

Artikel ini pertama-tama membahas keterbatasan skrip BTC, dan membahas beberapa solusi: mengatasi keterbatasan status UTXO dengan menggunakan komitmen BTC, menggunakan Taproot untuk melewati batasan ruang skrip, mengatasi batasan metode pengeluaran UTXO dengan menghubungkan output, dan mengatasi batasan presignature dengan kontrak. Selanjutnya, artikel ini memberikan gambaran komprehensif tentang fitur bukti penipuan dan bukti validitas, termasuk karakteristik bukti penipuan berlisensi dan tanpa lisensi, perbedaan antara bukti penipuan satu putaran dan multi-putaran, serta konten terkait teknologi pemecahan skrip BTC.

Pernyataan:

1. Artikel ini diambil dariaicoin], hak cipta milik pemilik asli [mutourend & lynndell, Bitlayer Labs], jika ada keberatan terhadap penyebaran ulang, harap hubungi tim Gate Learn, tim akan segera menanganinya sesuai prosedur terkait.
2. Penyangkalan: Pandangan dan pendapat yang terdapat dalam teks ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.
3. Versi bahasa lain dari artikel diterjemahkan oleh tim Gate Learn, tidak boleh disalin, disebarkan, atau ditiru tanpa menyebutkan Gate.io.